Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/main/java/org/sopt/kareer/domain/member/dto/request/MemberOnboardV2Request.java`:
- Around line 16-20: The fields universityCode and countryCode in
MemberOnboardV2Request are annotated with `@NotNull` which allows empty or
whitespace strings; change their validation annotation to `@NotBlank` so
empty/blank values are rejected and label lookup keys remain valid. Update the
annotations on the universityCode and countryCode fields in the
MemberOnboardV2Request class (same style as primaryMajorCode, name, targetJob)
to use `@NotBlank` with an appropriate message.

In `@src/main/java/org/sopt/kareer/domain/member/dto/request/MypageRequest.java`:
- Around line 22-35: MypageRequest has inconsistent validation and misleading
schema examples: change countryCode's annotation from `@NotNull` to `@NotBlank` (and
keep or harmonize validation messages) so empty/blank strings are rejected like
universityCode and primaryMajorCode, and update all `@Schema` example values for
countryCode, universityCode, and primaryMajorCode to show actual code formats
(e.g., "KR" or "AF" for countryCode, a university code token for universityCode,
and a major code token for primaryMajorCode) so API consumers see the expected
code strings; locate and modify the fields countryCode, universityCode, and
primaryMajorCode in class MypageRequest to apply these changes.

In `@src/main/java/org/sopt/kareer/domain/member/entity/enums/EnglishLevel.java`:
- Around line 9-11: The enum EnglishLevel was changed to use lowercase
descriptions which will break compatibility with existing DB values like
"Beginner"/"Intermediate"/"Advanced"; revert the enum descriptions in
EnglishLevel (the description strings passed to BEGINNER/INTERMEDIATE/ADVANCED)
to the original casing, and/or add a mapping method on EnglishLevel (e.g.,
fromDescription(String) or normalizeDescriptionForDb()) that accepts both
capitalized and lowercase forms and returns the correct enum so Member
persistence (which calls getDescription()) remains compatible; update usages
that serialize/deserialize englishLevelCode to use this mapping.

In
`@src/main/java/org/sopt/kareer/domain/member/entity/LocalizedOnboardCategory.java`:
- Around line 25-42: Add a unique constraint for the combination of fields type
and code on the LocalizedOnboardCategory entity and in the DB migration: update
the `@Table` annotation on class LocalizedOnboardCategory to declare a unique
constraint over columns "type" and "code" (e.g., uniqueConstraints =
`@UniqueConstraint`(columnNames = {"type","code"}, name =
"uk_localized_onboard_type_code")), and create a corresponding migration that
adds the unique index/constraint on the localized_onboard_category table
(resolving or deduplicating any existing duplicate rows beforehand so the
migration can apply cleanly); this will ensure findByTypeAndCode() returns a
single deterministic row.

In
`@src/main/java/org/sopt/kareer/domain/member/entity/LocalizedOnboardCategoryTranslation.java`:
- Around line 17-34: Add a DB-level unique constraint on (category_id, language)
to prevent duplicates: update the JPA entity LocalizedOnboardCategoryTranslation
by adding a uniqueConstraints entry on `@Table` for the (category_id, language)
pair, and create a database migration that (a) resolves or deduplicates any
existing duplicate rows for localized_onboard_category_translation and (b) adds
a UNIQUE constraint or unique index on category_id and language. Also review
callers like LocalizedOnboardCategory.updateTranslation(), addTranslation() and
any repository usages that assume multiple rows per language to ensure they
handle the uniqueness guarantee after migration.

In `@src/main/java/org/sopt/kareer/domain/member/entity/Member.java`:
- Around line 192-212: The updateProfile method mixes enum parameters (Degree,
EnglishLevel) with string codes for other fields which is inconsistent; change
the updateProfile signature to accept degreeCode and englishLevelCode as String
(instead of Degree and EnglishLevel), assign them directly to this.degreeCode
and this.englishLevelCode, and update all callers to pass the corresponding code
strings; keep the other parameters (countryCode, universityCode,
primaryMajorCode) unchanged so the API uniformly uses string codes.

In
`@src/main/java/org/sopt/kareer/global/external/ai/builder/context/MemberContextBuilder.java`:
- Around line 31-33: In MemberContextBuilder the university field is incorrectly
populated using member.getCountryCode(), causing "country" and "university" to
share the same value; update the appendLine call that sets "university" to use
member.getUniversityCode() instead (locate the appendLine(sb, "university", ...)
call and replace the getter), leaving the "country" and "primaryMajor" lines
unchanged.

In `@src/test/java/org/sopt/kareer/domain/member/entity/MemberTest.java`:
- Line 41: The test asserts the wrong getter: replace the call to
member.getUniversityCode() with the English level getter
member.getEnglishLevelCode() so the assertion compares the stored EnglishLevel
(e.g., EnglishLevel.BEGINNER) code value; update the assertion in MemberTest
(currently using getUniversityCode) to use getEnglishLevelCode() to validate
English level correctly.

---

Outside diff comments:
In `@src/main/java/org/sopt/kareer/domain/member/entity/MemberVisa.java`:
- Around line 40-52: MemberVisa still has visaPoint removed but tests and DTOs
reference it; remove all remaining visaPoint usages and align API/signatures:
delete the visaPoint field and any D10-specific validation from
MemberOnboardRequest, update MemberService.createMemberVisa call sites to match
the new signature (no visaPoint argument), and update test fixtures and
assertions—remove .visaPoint(...) builder calls in MemberVisaFixture, remove
.getVisaPoint() usages in MemberServiceTest and any assertions depending on it;
ensure MemberService and MemberOnboardRequest constructors/mapper logic no
longer expect or propagate visaPoint and rebuild tests to assert on existing
fields (e.g., visaType, visaStatus, visaStartDate, visaExpiredAt).

In `@src/main/java/org/sopt/kareer/domain/member/service/MemberService.java`:
- Around line 121-150: onboardMemberV2 currently calls String.join on
request.preparationStatuses() (and similarly fieldsOfInterests), which throws
NPE if those lists are null; update MemberService.onboardMemberV2 to defensively
handle nulls by defaulting to empty lists before joining (e.g., replace
String.join(",", request.preparationStatuses()) with a null-safe expression that
uses an empty list or empty string when request.preparationStatuses() is null)
or alternatively add `@NotNull` to MemberOnboardV2Request.preparationStatuses()
(and fieldsOfInterests if desired) so the DTO is validated; ensure to update
both preparationStatuses and fieldsOfInterests usages and keep the rest of
member.updateInfoV2 call unchanged.

---

Nitpick comments:
In
`@src/main/java/org/sopt/kareer/domain/member/dto/response/MemberInfoResponse.java`:
- Around line 5-6: Replace the wildcard imports in MemberInfoResponse by listing
the exact classes used from org.sopt.kareer.domain.member.entity and
org.sopt.kareer.domain.member.entity.enums; update the import statements
referenced in MemberInfoResponse (the class name MemberInfoResponse) to
explicitly import only the entity classes and enum types referenced in its
fields/methods (e.g., specific entity classes and enum names) instead of using
org.sopt.kareer.domain.member.entity.* and
org.sopt.kareer.domain.member.entity.enums.* to improve clarity and avoid name
collisions.
- Around line 61-86: The MemberInfoResponse.of factory method takes many
parameters (several consecutive Strings) which risks ordering bugs; refactor by
introducing a parameter object or builder: create a MemberLabels record or a
MemberInfoResponse.Builder and change MemberInfoResponse.of(Member, MemberVisa,
String... ) to accept the new MemberLabels (or use builder setters) and update
callers to pass the labels via that object or builder; adjust MemberInfoResponse
constructor/fields as needed and keep MemberInfoResponse.of(Member, MemberVisa,
MemberLabels) (or remove the static of in favor of Builder.build()) to make
parameter grouping explicit and prevent ordering mistakes.

In
`@src/main/java/org/sopt/kareer/domain/member/dto/response/MypageResponse.java`:
- Around line 54-59: The static factory MypageResponse.of currently takes five
consecutive String label parameters (countryLabel, primaryMajorLabel,
universityLabel, degreeLabel, englishLevelLabel) which is error-prone; refactor
by introducing a compact value object/record (e.g., MypageLabels or
LabelsRecord) to hold those label fields and change MypageResponse.of to accept
that single Labels type (or add a builder on MypageResponse that accepts/sets
labels via a Labels object); update all call sites that invoke MypageResponse.of
to construct and pass the new Labels instance (or use the builder) and adjust
MemberVisa/Member usages accordingly so parameter order mistakes are prevented.

In `@src/main/java/org/sopt/kareer/domain/member/entity/Member.java`:
- Around line 117-149: The updateInfoV2 method on Member accepts raw string
codes (countryCode, universityCode, englishLevelCode, degreeCode,
primaryMajorCode, etc.) without validation, risking data integrity; add
domain-level validation inside Member.updateInfoV2 (or helper methods it calls)
to validate/convert those code strings to the appropriate enums/typed values
(e.g., Country, University, EnglishLevel, Degree, Major) or lookup services and
throw a clear domain exception (e.g., InvalidMemberDataException) on invalid
codes, and only set the fields (fieldsOfInterest, preparationStatus,
languageLevel, etc.) after successful validation; ensure assertPendingStatus()
remains and keep setting status to MemberStatus.ACTIVE only when all validations
pass.

In
`@src/main/java/org/sopt/kareer/domain/member/service/LocalizedOnboardQueryService.java`:
- Around line 61-71: Extract the duplicated Locale extraction into a private
helper used by both resolveLabelByCode and toItemResponses: create a method
(e.g., getLocaleLanguageInfo or resolveLocaleInfo) that calls
LocaleContextHolder.getLocale(), computes languageTag and language (handling
null), and returns them in a small holder (e.g., a simple record/DTO or
String[]); then replace the inline Locale/ languageTag/ language logic inside
resolveLabelByCode and toItemResponses with a call to this new helper and use
its returned values when calling resolveLabel.